<?php
/**
 * <https://y.st./>
 * Copyright © 2017 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Assembly',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<section id="dental">
	<h2>Dental appointment scheduling</h2>
	<p>
		There was no way I was going to make it to the other dental office without directions.
		I couldn&apos;t send them to my mobile via $a[USB], seeing as it&apos;s $a[USB] port has quit functioning for data transfer, and I don&apos;t have ink for my printer.
		In fact, I&apos;ve never had ink for my printer; I don&apos;t even know what type of ink cartridge it takes and haven&apos;t sat down to try to figure it out yet.
		I ended up sending the directions to myself via email.
		I didn&apos;t understand the first pat of the directions, but they were supposed to get me to Harlow Road, so I skipped them and just went to Harlow Road the easy way.
	</p>
	<p>
		Once on Gateway Street, I was supposed to follow it until it became North Game Farm Road, but I&apos;m not familiar with the area.
		There was a perpendicular street, Game Farm Road, so I stopped at a bank and asked if Game Farm Road turns into North Game Farm Road if I followed it.
		They confirmed that it did.
		I followed it, and it did nothing of the sort.
		I forget what road it became, but Game Farm Road South branched off of it.
		I forget where I went exactly, but I turned back and tried to head in the general direction that the map seemed to want me to go in.
	</p>
	<p>
		That didn&apos;t work out, and I ended up stopping at some sort of medical care centre and asking for directions there.
		As I biked in, I set off two strange detectors set up that made noise as I went through them.
		I thought they might be some sort of alarm system or something and that they alert people inside that someone has entered the grounds.
		Once inside, I asked the receptionist for directions, and they along with someone else waiting in the lobby helped me figure out where to go.
		Strangely, the receptionist kept referring to me as a &quot;she&quot; at first, then at the end, referred to me as a &quot;he&quot;.
		It was a bit amusing.
		Can you make up your mind as to what gender you think I am?
	</p>
	<p>
		Their directions took me back to Gateway Street, which was pretty much where everything in the directions I&apos;d brought went wrong.
		From there, I was told to go directly to Crescent Avenue; the directions I brought from home told me to take Gateway Street to North Game Farm Road and <strong>*then*</strong> turn onto Crescent Avenue.
		If I could skip North Game Farm Road altogether, I could skip the confusion.
		I followed Gateway looking for Crescent Avenue, and found it and the spot Gateway Street becomes North Game Farm Road together in the same spot.
		So, my original directions were technically correct, though they&apos;d also be correct if they&apos;d left out the part about North Game Farm Road, and North Game Farm Road is perpendicular to Game Farm Road, though it&apos;s in a different location.
		Streets that change names at certain points and streets bearing basically the same name are confusing when you don&apos;t know the area.
		Who decides to set up this garbage?
	</p>
	<p>
		I had to take an afternoon appointment or wait a long time to get an appointment at all.
		Reluctantly, I took the first available appointment, which will be on Wednesday.
		I usually don&apos;t work on Wednesdays, so I was hoping not to have a scheduled shift.
		I won&apos;t know until tomorrow whether I have a shift for sure or not though.
		There&apos;s still a delay, as the oral surgeon is currently on vacation, but I still got an appointment pretty quickly.
		It makes me wonder how quickly appointments with the surgeon can usually be made.
		Had the dental office contacted me right away like they said they would, I might&apos;ve been able to be seen before the trip out of town.
		But now, they&apos;re likely going to need to cut into my gums, as the existing hole is closing up and might not be large enough by the time of my appointment.
	</p>
</section>
<section id="university">
	<h2>University drudgery</h2>
	<p>
		The school sent me a year&apos;s end survey to fill out.
		I&apos;m not sure why I did fill it out instead of just ignoring it.
		Seeing as the school&apos;s not on our side anyway, it&apos;s not like I think my filling it out will actually improve anything.
	</p>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<h3>The Hack assembler is a two-pass assembler. Explain why there is a need for going twice over the code.</h3>
		<p>
			At first glance, it doesn&apos;t look like two passes would be needed.
			As variables are used, they can be bound in place in the same pass as the regular code parsing.
			The problem come in when we start using labels for jumps.
			If a jump sends us to a previous point, we&apos;ve already seen and recorded the label; we&apos;re good.
			However, if we need to jump <strong>*forward*</strong> in the code, we won&apos;t recognise the label; we won&apos;t know where to jump.
		</p>
		<p>
			Using a two-pass compilation method, the first pass can find all the labels, while the second pass can assemble the code knowing what section of the code each label refers to (Nisan &amp; Schocken, n.d.).
			The variable names are collected in the second pass.
			The book doesn&apos;t exactly tell why, but if we think about it for a bit, the reasoning becomes apparent.
			Variable references are used in A-commands the same way label references are.
			The only way we can know that a symbol is a variable is by knowing it&apos;s <strong>*not*</strong> a label, so we need to already know what labels we have.
			(That is, except for pre-defined symbols; we know what those refer to without knowing any of the labels.)
		</p>
		<h3>There is a method named backpatching that solves this issue with one pass only. Describe this method.</h3>
		<p>
			Backpatching is assembling all the code as best you can as you first come across it, recording the locations of unknown symbols as you encounter them, then going back and patching the previously-assembled code once the symbols have been added to the symbol table (Scribd Inc., n.d.).
			As some of the symbols are unknown at the time they&apos;re used, some of the assembled code will be incorrect until the later patching.
			The locations in which unknown symbols are used can be stored in a table so the assembler knows where to return to once the symbol table is complete.
			Arguably, the assembler could also check for relevant entries in the table when encountering a new symbol definition as well, removing those entries from the table and patching right away instead of doing all the patching at the end.
		</p>
		<h3>What are the pros and cons for one pass assembly vs. two pass assembly?</h3>
		<p>
			One-pass assembly is faster, as the assembly code only needs to be parsed once.
			However, it requires holding the entire binary representation in $a[RAM] to allow later patching.
			That is to say, the assembler can&apos;t write the output directly to a file as it works.
			That not only limits how much $a[RAM] is available to other programs, but also limits the size of the to-be-assembled program.
			Two-pass assembly may take more time to complete, but at least it doesn&apos;t take much $a[RAM].
			Which method you use should be determined by your use case and what resources you&apos;re more concerned with preserving.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Nisan &amp; Schocken. (n.d.). Assembler. Retrieved from <a href="https://my.uopeople.edu/mod/resource/view.php?id=132887"><code>https://my.uopeople.edu/mod/resource/view.php?id=132887</code></a>
			</p>
			<p>
				Scribd Inc.. (n.d.). Introduction to Assemblers | Assembly Language | Instruction Set. Retrieved from <a href="https://www.scribd.com/document/29871446/Introduction-to-Assemblers"><code>https://www.scribd.com/document/29871446/Introduction-to-Assemblers</code></a>
			</p>
		</div>
	</blockquote>
</section>
END
);
